The present specification generally relates to verification of configuration actions in particular in self-optimizing networks and more specifically relates to post-action verification in self-organizing networks.
Self-organizing network (SON) features are seen today as the key enablers for automated network management in next generation mobile communication networks such as Long Term Evolution (LTE) and LTE-Advanced (LTE-A). SON features can be grouped into three main areas: self-configuration, self-optimization and self-healing.
The first area, i.e. self-configuration, typically focuses on the initial configuration and auto-connectivity of newly deployed network elements (NE).
The second area, i.e. self-optimization, targets the optimal operation of the network. A network enabled for self-optimization automatically adapts configuration parameters which should lead to improved robustness, reliability and throughput.
The third area, i.e. self-healing, is responsible for fault detection and resolution, e.g., caused by malfunctioning hardware or faulty software.
These three core functionalities are available through the use of so-called SON functions. Such functions are designed to work independently from each other.
In order to fulfill their tasks the SON functions monitor certain key performance indicators (KPI), configuration changes and alarm occurrences in the network.
After gathering the required amount of information, a SON function instance may get active (i.e., run its algorithm) in order to compute new configuration management (CM) parameters and enforce them on the NEs requiring reconfiguration.
Due to the fact that SON function instances may perform changes to network configuration parameters during their operation, a SON coordinator is required to reject the requests which would cause or engage in conflicts and allow those, which would guarantee a flawless network operation.
These approved requests will trigger the actual configuration of their corresponding network parameters. This type of coordination is usually referred to as pre-action SON coordination and is based on rules used to anticipate and avoid known conflicts between SON function instances.
In addition, there are two important properties of a SON function instance required for coordination: the impact time and impact area.
A SON function instance has to be considered by a SON coordinator during the complete time period during which it is active. This time period is also known as the impact time. This time period includes not only the delay required to perform measurements, run the algorithm and compute new configuration parameters, but also the time required to deploy the new configurations and the time until they become relevant for subsequently active functions.
The impact area is the spatial scope (at the cell level) within which a SON function instance modifies configuration parameters or takes measurements. More precisely, it contains the function area (area that is directly configured), the input area (area where the measurements are taken from), the effect area (the area that contains the cells that are affected by a CM change), and a safety margin (an extension to the effect area).
However, approved network configuration changes may not necessarily lead to improved performance targeted by the corresponding network functions and, even more so for the network-wide performance defined by operator specific criteria.
This is caused by the fact that the SON coordinator focuses only on the conflict detection and coordination. An operator may, therefore, compensate this by adding a post-action verification mechanism to determine whether a configuration change leads to a significant change in performance. It aims at computing statistical measures on performance indicators at a relevant spatial and temporal aggregation level to assess quickly the impact of a set of (SON-induced) configuration changes. This may be done independently of the semantics of those configuration changes such that also performance impacts with unknown causes can be identified. The approach can be classified as a specific type of anomaly detection.
FIG. 3 outlines the integration of a verification mechanism as discussed above. In particular, FIG. 3 gives an overview of the above discussed SON operation entities (management, coordination, verification) in a SON-enabled network. The mechanism is implemented as a SON function (the SON verification function 31C) which is seeded with CM, Performance Management (PM) and Fault Management (FM) data 319 from the corresponding databases (CM database 37, PM database 38) and the FM 39 in order to achieve its task.
As soon as enough data is collected, the SON verification function 31C tries to determine whether the network experiences performance degradation. If this is the case, it sends an undo execution request 311 to the SON coordinator 32 and reverts 318 the CM changes of the affected cells made by a given SON function instance 31A, 31B after receiving the corresponding acknowledgement 312.
As FIG. 3 depicts, a human operator (via SON management 33) is always informed about the current state of the CM parameters, KPIs as well as fault occurrences in the network. The operator is also able to manually adjust (300) CM parameters.
However, the SON verification function 31C becomes useful only when it is known when and where to apply it. For this reason, the SON verification function 31C identifies the cell or a set of cells affected by a (set of) CM change(s).
To do so, the SON verification function 31C computes a verification area which is the spatial scope that is observed for anomalies. It consists of a set of cells (“CM change base area”) that have been reconfigured by SON function instances 31A, 31B and a set of cells (“CM change extension area”) that have been possibly influenced by that reconfiguration process.
In addition to the above mentioned entities the SON environment shown in FIG. 3 further comprises the following arrangement.
SON functions 31 may consist of several SON functions, e.g. SON function A (31A) and SON function B (31B), each implementing a respective SON function algorithm (SON function algorithm A (31Aa), SON function algorithm B (31Ba)).
The SON verification function 31C, which is also a SON function 31, implements a verification algorithm 31Ca.
The SON management 33 may configure the SON functions 31 via respective configurations, e.g., verification function configuration 313, a function B configuration 314, and a function A configuration 315.
The SON management 33 may further configure the SON coordinator 32 via a coordination configuration 310.
CM configurations (e.g. CM configuration A 316 and CM configuration B 317) are transmitted to a plan assembly 34, where the respective configurations are forwarded to and implemented at respective evolved NodeBs (eNB, eNodeB), e.g. eNodeB A (35) and eNodeB B (36), serving cells 35A to 35C and 36A to 36C, respectively.
Execution requests 311 and execution permissions 312 are interchanged between the SON functions 31 and the SON coordinator 32.
In view of the above, a verification mechanism is known to be implemented as a SON function. The main reason for proposing such a function is to solve the issues caused by uncoordinated CM undo operations. The verification scope may be defined e.g. as all cells controlled by a certain controller such as a base station controller (BSC) or a radio network controller (RNC).
A known verification function includes four major phases which are depicted in FIG. 4, which, in other words, illustrates a general overview of such verification.
The mentioned phases are a CM change activity observer 41, a verification area generation 42, a performance assessment 43, as well as a decision (44) to accept (44A, “PASSED”) or undo (44B, “FAILED”) the CM changes (made by a human operator, a script, a given SON function instance or any other source).
The following problems arise when implementing the known verification of configuration actions approach.
One problem is very basic in that according to known techniques the phase 43 is done once followed by an immediate decision 44. While this behavior leads to a fast undo 44B, the assessment 43 and thus the decision 44 are very sensitive to short-term perturbations of the system, and thus the decision 44, whether a (set of) configuration changes leads to a good or bad result may be not at all reliable.
FIG. 5 illustrates multiple CM changes made by a single SON function instance and is used to describe a further problem of the known verification of configuration actions approach.
For description, a SON function instance A is supposed, whose function area 51 includes not just one cell, but, e.g., all cells of an eNodeB 52 (e.g. cell 1 (53), cell 2 (55) and cell 3 (54). It is further supposed that this SON function A changes two parameters at two of the cells (namely, changes parameter “X” at cell 1 (53A), and changes parameter “Y” at cell 2 (55A)).
In case one of those changes induces degradation in performance, the known verification function will undo all changes within the CM changes base area (which equals the function area 51 as known from above). As a consequence, the changes made at cell 1 (53) as well as cell 2 (55) will be undone even if one of them has had a positive impact on the network performance.
A still further problem is that the known technique is not able to prevent SON function instance A from redoing the harmful change (i.e. the change with the bad result) over and over again. If the above mentioned SON coordinator would be used to block the request of SON function instance A, it would lead to the blocking of all requested CM changes, even those that might have a positive effect on the network. If we take the notation introduced in FIG. 5, changes “X” (53A) and “Y” (55A) will be blocked even if one of them improved the performance and was, therefore, necessary.
The main reason for this to happen is that SON function instances are not informed about the impact of their changes and are in no position to filter their requests before sending them to the SON coordinator.
It should be noted that X and Y above can refer to both a change of the same or different parameter types. There are SON functions, e.g., a capacity and coverage optimization (CCO) function, which have the ability to change two different CM parameters (e.g., the transmission power and the antenna tilt in case of the CCO function).
Hence, the problem arises that merely an ineffective verification of configuration actions approach is known, according to which the decision, whether a configuration change leads to a good or bad result may be not at all reliable, changes may be undone even if one of them has had a positive impact on the network performance, and a according to which configuration change that leads to a bad result can be repeatedly set.
Hence, there is a need to provide for verification of configuration actions.